LP-0001: rewrite as an NFT extension of LP-0021 with adoption criteria - #152
Open
fryorcraken wants to merge 17 commits into
Open
fryorcraken wants to merge 17 commits into
fryorcraken wants to merge 17 commits into
Conversation
✅ Validation passedA reviewer will assess against the prize criteria. Automated check. See solution template and TERMS. |
fryorcraken
force-pushed
the
lp-0001-nft
branch
4 times, most recently
from
September 17, 2026 02:39
a6185bc to
3f78af4
Compare
LP-0021 scoped NFTs out so the wallet could ship fungible-asset support quickly. Recast LP-0001 as the prize that fills that gap, following the same extension pattern LP-0022 uses: it builds on the LP-0021 feature set (wallet, Wallet Provider SDK, approval flow) rather than a specific codebase, so the LP-0021 winner, another team, or a fork can all bid. Leads with basic NFT features (own, transfer, collection-grouped display, SDK enumeration and transfer proposals); the private collection-membership proof becomes one criterion among several rather than the whole prize, surfaced through the SDK and a token-gating reference mini app. Adds an Adoption section mirroring LP-0022's structure, including the same-team-vs-fork inheritance rule, and moves the prize to the adoption-first table in README. Prize set at $5,000 / Medium. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…to build on State the baseline wallet adoption rule in one direction: waived for the LP-0021 winning team continuing that codebase, required of every other submission. The previous phrasing stated the rule twice, in inverted order. Reword the Motivation so it does not read as a recommendation to build on another team's codebase, and drop the Out of Scope bullet that repeated it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Drop "continue to" and "Extending" phrasing that presumed a build carried over from LP-0021; state what a submission must do instead, reusing LP-0021's own wording where the criterion is the same. Also remove em dashes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
"This prize extends a LEZ wallet..." reads as modifying an existing build. State what the prize is for instead, matching the "matching the criteria in LP-0021, covering X" construction used in Scope. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
fryorcraken
force-pushed
the
lp-0001-nft
branch
from
September 17, 2026 02:48
3f78af4 to
9fd555f
Compare
Nothing stopped a wallet from requiring account access before producing a membership proof, which would defeat the privacy the proof provides. Make proof requests their own SDK capability: a dApp granted only a proof request learns no address, balances, holdings, or the proving token, and a wallet may not demand account access to produce a proof. Require the proof-request prompt to be visibly distinct from an account-access prompt and approved separately, so a user cannot inadvertently share an account address while sharing proof of ownership, and require granted capabilities to be individually visible and revocable. Drop "account selection" from the token-gating flow throughout, since that flow must now work without it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
NFT metadata and media are the one case where a wallet genuinely wants a remote resource, which LP-0021's generic external-services rule does not cover. Require any non-Logos-Storage media fetching to be disclosed, disableable, and non-leaking of which account holds an asset, with the wallet still usable when it is off. Require upload and download of image-sized metadata and media via Logos Storage. State that the criteria are a minimum: submissions may go further wherever a team judges it necessary for adoption, and Out of Scope means not required rather than forbidden. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The criterion covered any source other than Logos Storage, which would have swept in decentralised networks it was never aimed at. Name centralised services instead (HTTP hosts, gateways, CDNs, hosted pinning or indexing APIs) and say explicitly that fetching over a decentralised network the user participates in is not subject to it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The adoption criteria repeatedly call for independent or third parties without saying whether people already building the stack qualify. State it once in the preamble: core contributors are welcome to use the wallet, but do not count toward the numbers. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This reverts commit 44b24ea. Awaiting phrasing from legal. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…erification A proof is only useful if the thing receiving it can check it, and most consumers are not LEZ programs. Require the reference mini-app to show both paths: the proof passed as input to a reference LEZ program that gates an action on the result, and the mini-app verifying the proof in its own code and showing the user what it establishes. Add off-chain verification as its own criterion with a library and the inputs a verifier needs, and require the on-chain verifier and the library to agree on accept/reject outcomes. The on-chain flow remains the one that feeds the adoption criteria. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The adoption criteria cover usability: a wallet that 3 third-party developers build on and 100 accounts use through the mini-app has demonstrated it works better than a recording could. Fold the one requirement the video carried, evidence that proving ran for real rather than in mock mode, into the demo-script criterion the evaluation process already relies on, and extend that script to cover the full proof flow. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Restore the LP-0021 and LP-0023 dependencies with legal's note that the front matter is internal reference and tooling only, matching LP-0022. The README row is already in place, so the reminder comment has served its purpose. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The criterion asks for source-verification status and says a registry meeting or similar to LP-0023's specifications will be suitable. That is a pointer, not a dependency. LP-0023 stays in Resources. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
fryorcraken
marked this pull request as ready for review
September 17, 2026 03:13
xAlisher
reviewed
Sep 17, 2026
There was a problem hiding this comment.
Reviewed against the private-NFT work I did (ownership + unlinkable transfer + viewing-key disclosure, with a passing POC on the real token program). Solid spec, honest framing. Three notes:
ADD - unlinkable private transfers. Criteria require send/receive from private accounts but never that a private NFT transfer is unlinkable to a chain observer (no sender->recipient edge). That is the core shielded property, and I verified it holds on Logos in my POC (private->private transfer records only commitments, no public owner, no edge). Worth a reliability criterion so "private account support" cannot pass while transfers stay linkable.
QUESTION - proof freshness. Replay resistance is per-context, not per-state. Does a membership proof bind to CURRENT ownership, so someone who transferred the NFT out can no longer gate? For token-gating that matters. Open design point (I have not solved it either), not a copy-this note.
SCOPE - one line stating this is collection-membership proof, not selective disclosure of a specific asset, would stop submitters conflating them.
Otherwise no removals; scope boundaries are good.
# Conflicts: # prizes/LP-0001.md
Adds reliability criteria for unlinkable private-to-private transfers and time-bound proof freshness with per-token proof supersession, and clarifies that the membership proof is collection-level, not selective disclosure of a specific asset. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #122 (
wallet), since LP-0021/LP-0022 only exist on that branch. Base should be retargeted tomasteronce #122 merges.What this does
Recasts LP-0001 from a standalone ZK bounty into LP-0001: NFT Wallet Support and Private Ownership Proof — an extension of LP-0021, following the same pattern LP-0022 uses.
LP-0021 deliberately scoped NFTs out so a winning team could ship fungible-asset support quickly. This prize fills that gap and turns it into a token-gating primitive dApps can consume.
Key decisions
Adoption criteria
Mirrors LP-0022's structure, including the same-team-vs-fork inheritance rule:
Worth a look during review
RISC0_DEV_MODE=0. Per the house rule that prize docs specify product requirements rather than implementation, this is now "proving enabled rather than a development/mock mode" — the anti-cheat intent survives without naming a stack. Easy to make prescriptive again if that is preferred.Status: draft - pending NFT Program readinessline is dropped (LP-0021/22 carry onlyLogos Circle), and the standard spec disclaimer is appended.🤖 Generated with Claude Code